home *** CD-ROM | disk | FTP | other *** search
-
-
- IETF STEERING GROUP (IESG)
-
- REPORT FROM THE TELECONFERENCE
-
- AUGUST 15TH, 1991
-
-
- Reported by:
- Greg Vaudreuil, IESG Secretary
-
- This report contains
-
- - Meeting Agenda
- - Meeting Attendees
- - Meeting Notes
-
- Please contact IESG Secretary Greg Vaudreuil
- (iesg-secretary@nri.reston.va.us) for more details on any particular topic.
-
-
- ^L
-
- A. Meeting Attendees
-
- Almquist, Philip / Consultant
- Borman, David / CRAY
- Callon, Ross / DEC
- Chiappa, Noel / Consultant
- Crocker, Dave / DEC
- Crocker, Steve / TIS
- Coya, Steve / CNRI
- Davin, Chuck / MIT
- Gross, Philip / ANS
- Hobby, Russ / UC-DAVIS
- Hinden, Robert / BBN
- Vaudreuil, Greg / CNRI
-
- Regrets
-
- Estrada, Susan / CERFnet
- Reynolds, Joyce / ISI
- Stockman, Bernard / SUNET/NORDUnet
-
- B. Agenda
-
- 1) Administrivia
- - Bash the Agenda
- - Approval of Minutes
- - July 25th
- - July 30-Aug 2nd
- - August 8th
-
- 2) Review of Action Items
-
- 3) Protocol Actions
- - MIB 2
- - Concise MIB
- - Network Time Protocol
- - Multi-protocol interconnect over Frame Relay
- - Inverse ARP
- 4) RFC Editor Actions
- - Message Send Protocol 2
- - SNMP over OSI
-
- 5) Technical Management Issues
- - TCP Large Windows extensions
- - Many MIBs
- - Distinguished Names
- - Five Full-Day IETF Meetings
-
- 1. Administrivia
-
- 1.1 Approval of the Minutes
-
- 1.1.1 July 25th. The Minutes of the July 25th Teleconference were
- approved pending changes to be sent to Vaudreuil by Monday.
-
- 1.1.2 Plenary Meetings. These minutes were approved by the IESG
- pending changes to be send to Vaudreuil by Monday. The Chairman later
- asked that these be delayed pending his review and approval.
-
- 1.1.3 August 8th. These minutes were not approved by the IESG. They
- will be read, corrected, and resubmitted for the next teleconference.
-
- The IESG discussed the imminent release of the minutes beginning with
- the plenary session meetings. The preferred distribution mechanism was
- chosen to be a sister directory to the ietf and internet-drafts, with
- an announcement sent to the IETF mailing list of their availability.
-
- ACTION: Vaudreuil -- Make a new distributed directory for the IESG
- minutes. Insure that mail access is available at the NIC.DDN.MIL
-
- 2. Review of selected action items.
-
- (89) Apr 25 [Russ Hobby]
- Resolve the conflict with the two version of the IMAP
- protocol.
-
- There is slow progress being made. One party is now willing to change
- the name of the protocol and declare a split. The other party is
- talking in good faith to resolve this issue and may also agree to a
- name change.
-
- (170) Aug 08 [Phill Gross]
- Communicate the opinion of the IESG concerning the
- Interactions of BGP with IGP's to the authors of the BGP
- Usage document and integrate the useful Interaction
- information into the document.
-
- Phill Gross has been in contact with Yackov Rekhter and is
- awaiting comments on the latest version of the document. The IAB is
- continuing to send mixed signals on the BGP usage document. After
- significant discussion, the IESG determined that it has done all it
- can to address the IAB's concerns on this document.
-
- Specific objections were raised about the lack of a routing
- architecture document for BGP. While the IESG agrees that there is a
- pressing need for an unified routing architecture, it feels that this
- document is not required for specific routing protocols, and imposing
- this requirement on the BGP protocol designers would unduly delay the
- well deserved advancement of the BGP protocol.
-
- The IESG agreed to send the current set document to the IAB as soon as
- all the authors are polled. If at that point the IAB still has
- objections, these should be send to the IESG and IETF in the form of
- an explicit rejection notice.
-
- ACTION: Gross -- Send a note the IAB soliciting final comments on the
- BGP documents. Explain that the IESG is satisfied with the current
- BGP documents expects to make a public recommendation in the near
- future.
-
-
- (168) Aug 08 [Phill Gross]
- Write a statement to the IAB expressing the need felt by the
- IESG for a public response to the public IESG recommendations
- to the IAB.
-
- This action is still pending. The IESG discussed and reiterated the
- need for these formal exchanges and notification of standards actions.
-
- 3. Protocol Actions
-
- 3.1 Management Information Base II
-
- The IESG approved the recommendation elevating MIB II to full Standard
- status. MIB II is widely implemented in network devices and
- management stations.
-
- 3.2 Concise MIB Definitions
-
- The IESG approved the recommendation elevating the Concise MIB
- definitions to Draft Standard. This new compact machine readable
- syntax is used in all recent MIBs written, including MIB II.
-
- 3.3 Network Time Protocol Version 3
-
- The IESG approved the recommendation for the Network Time Protocol
- Version 3 for Proposed Standard. While there was sentiment within the
- IESG for skipping the proposed standard state for this particular
- protocol, wowever it was feared that figuring out the rational for an
- exception in the understood practice may take far longer than the 6
- months the protocol would otherwise remain in the Proposed Standard
- state.
-
- 3.4 Multi-protocol Interconnect over Frame Relay
-
- The IESG discussed this document, and found it to be a good
- specification. One policy concern was raised, and should be
- communicated with the author. Historically the IAB has standardized
- IP on top of networking technologies and has avoided standardizing
- protocols for running other protocols over these networking
- technologies. An exception has been made for the point to point
- protocol where no other standard multi-protocol point to point
- protocol was available. In this case the IAB will assign protocol
- numbers and will likely standardize the specification of third party
- protocols over PPP. In the case of Frame Relay, it is not clear who
- "owns" the specification. Normally the IAB would standardize only IP
- over Frame Relay. In addition to specifying IP over Frame Relay, this
- document also specifies the general case of Foo over Frame Relay.
- Given the uncertain ownership of the frame relay specification, and
- the need for multi-vendor interoperation, the IESG has no problem with
- this specification. It is recommended that the title be changed to
- reflect the more traditional standardization emphasis of IP over Foo,
- such as "IP and other protocols over Frame Relay".
-
- ACTION: Vaudreuil -- Talk to author of the Multi-protocol Interconnect
- document about the name of this document; report results to IESG.
-
- 3.5 Inverse ARP
-
- The IESG discuss this document. While the protocol accomplishes that
- specific task it was written to, it is not clear from the document why
- a new protocol was needed. Other address resolution mechanisms exist.
- The IESG has been convinced that the Inverse ARP protocol is in fact
- a good way to proceed with the specific requirement posed by Frame
- Relay networks.
-
- The IESG recommends to the author that a section documenting the
- design criterion and rational for this new protocol be written to
- capture the reasoning behind this novel extension of the architecture.
-
- ACTION: Vaudreuil -- Talk to the author of the Inverse ARP protocol
- about the need for a section documenting the design criterion and
- rational for the Inverse ARP protocol.
-
- ACTION: Vaudreuil -- Encourage the writing of a rational section for
- the Inverse ARP document.
-
- MAYBE-POSITION: A rational should be captured in Internet Drafts.
- Need to avoid a making this a major burden. It helps capture for
- future readers who may not know the word of mouth history.
-
- 4. RFC Editor Actions
-
- 4.1 Message Send Protocol
-
- The RFC editor sent the IESG an experimental protocol, the Message
- Send Protocol for review and comment on August 13th. The IESG found
- the document interesting but members did not have time to review this
- before todays meeting. This protocol may impact the SMTP extensions
- work with regard to the SEND command.
-
- ACTION: Hobby -- Review the Message Send Protocol for the RFC Editor
- before August 27th.
-
- 4.2 Finger
-
- The RFC Editor has received a new version of the Finger protocol.
- This revision corrects inconsistencies between the protocol and common
- implementations. Hobby reviewed the protocol and found the protocol
- to be consistent with current practice, and recommends republication
- at the current Draft Standard State.
-
- The RFC Editor forwarded to the IESG a message from an implementor
- of the protocol who has identified several other minor points that
- could use clarification.
-
- ACTION: Hobby -- Look at the list of enhancements for the Finger
- protocol and determine if these should be corrected in this re-release.
-
- 4.3 SNMP over OSI
-
- Marshall Rose has submitted a new version of the SNMP over OSI
- experimental protocol specification. The intent is in part to provide
- a template for future authors to use in writing SNMP over Foo protocol
- documents. The question was raised about whether these SNMP over FOO
- are in fact experimental or Standards Track specifications. The
- Network Management Directorate clearly believes that SNMP should be
- run only over UDP, and has enunciated that position in Internet Draft
- <draft-ietf-snmp-commservices-00.txt>. The question remains as
- community support for using SNMP over proprietary network technology
- grows.
-
- Due to lack of time, the IESG was unable to discuss this in greater
- depth.
-
- ACTION: Vaudreuil -- Schedule time in a future teleconference to
- discuss the wisdom of running SNMP only over UDP.
-
- 5. Technical Management Issues
-
- 5.1 Multitude of MIBs
-
- There is a half a dozen MIB's that have been reported out of the
- working group and are now being reviewed by the Network Management
- Directorate. The IESG Secretary has been tracking these as IESG
- protocol actions. This newly improved MIB tracking has made clear an
- element of confusion. MIBs generally receive their Network Management
- Directorate review after the relevant WG has reached closure on the
- MIB. Confusion arises when WGs chartered outside the NM area submit
- MIBs directly to the IESG without first submitting them for NM review.
- This confusion leads to an increasing number of situations in which
- the directorate is asked to conduct hasty reviews in order that the
- perceived timetable of IESG business not be unduly delayed, rather
- than conducting these reviews as part of the normal, 4-month cycle of
- NM directorate business.
-
- The NM AD expressed the view that, for tracking purposes, the NM
- review should be regarded as a distinct step between WG closure on a
- MIB and its submission to the IESG. In this way, time invested for the
- NM review would be accounted as part of routine progression of the
- document, and the quality of the review itself would not suffer from
- the time pressures of being a part of the IESG consideration of the
- document, which often has very different requirements.
-
- 4.2 TCP Large Windows
-
- Dave Borman gave a review of the TCP Extensions for Large Windows
- protocol situation. The current status is a bit unclear at this time.
- It appears that Braden, acting as the executive director of the IAB
- rejected the protocol for proposed standard for the IAB and has
- reassigned control for further evolution of the protocol to the End to
- End research group of the IRTF. This situation is not normal.
-
- Borman discussed the specific technical problems with the extensions,
- and discovered that both the CRAY implementation and the LBL
- implementation of this protocol interpret the documents differently.
- Borman feels that the protocol needs a bit more engineering, but is
- essentially functional as demonstrated by the error free
- interoperation between the two independent implementations. A question
- was raised about the proposed standard status. There was the notion
- that a proposed standard needs a credible specification, but does not
- need to be perfect. Changes are expected as experience with
- implementation and testing is gained prior to draft standard.
-
- Several things are unclear. Braden is one of the authors of the
- documents, as is Van Jacobsen. It is unknown whether Jacobsen in fact
- desires to delay the standardization of these protocol extensions. If
- both authors wish to withdraw the specification from consideration,
- the IESG agreed that is should not push the specification forward.
- There are now two other proposals for extending the TCP sequence
- space, one of which is under discussion in the End to End Research
- group. A new proposal from UCL has been circulated privately. If
- there are in fact competing proposals, there may be need to resurrect
- the TCP Large Windows working group.
-
- ACTION: Borman -- Get a copy of the UCL TCP proposal and distribute it
- to the IESG.
-
- 4.3 Distinguished Names
-
- A preliminary discussion of the need for a Distinguished Name Service
- in the Internet demonstrated immediately the need for a lengthy
- technical discussion of this issue. There is great need for such a
- service, and several platforms from which it may be built. A separate
- teleconference was planned, to be led by Steve Crocker and Russ Hobby.
-
- ACTION: Hobby, S. Crocker -- Organize an agenda for the Distinguished Name
- Teleconference. Work with Vaudreuil to schedule an appropriate time.
-
-
- 4.4 Full Five Day IETF meetings.
-
- The IESG received many comments during the last plenary session in
- Atlanta Georgia about the need to reduce the number of simultaneous
- working group sessions, and the need for more time to meet. In
- response to this need, and with the sense of the open plenary, the
- IESG agreed to adjust the schedule of the next meeting to include an
- additional working group session and extend the schedule to run to
- 3:30.
-
- Action: Coya -- Work with the IETF Chairman to plan a revised IETF
- plenary agenda to include one additional working session.
-
-